Which issue does this PR close?

• Closes CREATE TABLE AS not checking column unicity #22167

Rationale for this change

CREATE TABLE AS, CREATE VIEW, and SELECT INTO can persist only plain
column names.

Before this change, a query like a self join could produce qualified output
columns such as x.column1 and y.column1, which are valid while planning.
But when the table or view was created, those qualifiers were dropped and the
stored schema became column1, column1, ... with duplicates.

That meant the create step succeeded, but the created table or view failed
later when the user tried to read from it. The object existed in the catalog
but was not usable.

This PR fixes that by rejecting these cases during execution of the DDL
operators, before the table or view is registered.

What changes are included in this PR?

This PR adds an execution-side check that validates the final output schema has
unique unqualified column names.

It applies that check in:

• create_memory_table
• create_view

This covers:

• CREATE TABLE AS
• CREATE VIEW
• SELECT INTO

The check runs after optimization or type coercion and before registration, so
it validates the actual names that would be stored.

For IF NOT EXISTS, execution keeps the existing no-op behavior when the
target already exists, so validation only runs when a new object would
actually be created or replaced.

This PR also adds:

• sqllogictest coverage for the duplicate-column self-join case for all three flows
• direct execution-level regression tests for create / replace table and view paths

Are these changes tested?

Yes

Are there any user-facing changes?

Invalid CREATE TABLE AS, CREATE VIEW, and SELECT INTO statements that
would create an object with duplicate unqualified column names now fail early
during DDL execution with a schema error, instead of succeeding and creating
an unreadable table or view.

No API Changes